State Modeling Using State Machine

This topic describes state modeling using the concept of state machine.

The concepts of state machine are used while designing a state model. For information on state machine, refer to State Machine.
It is important to remember the following points before you design a state model:

• State model is applied only on the hub entity inside the Hub data store
• The "Enable business object life cycle" must be enabled to model a state flow diagram for the hub entity
  
  To understand how the concept of state engine is used to model and control the object life cycle, consider below example. 
  
  Note : Below is just a representation of state model(not exact to the design time modelling) where "Update COD" means "update hub entity"
  
  
  This model has three states, Update COD (being the initial state) which updates the COD table and automatically transits to the 'Update Spokes' state which updates the spokes and then transits automatically to the WAIT state. The behavior is as follows:
  
  For MDM synchronization, create a hub-and-spoke model and configure publishers for each of the spokes. Each publisher sends the changes to MDM Service. It receives these changes and triggers the state flow for each change (instance). For each such instance, MDM Service would create a new state model instance and forward it to the state engine. As per the model, the initial state is 'Update COD', and the new instance would straight away come into the state Update COD. Here the entry part has an activity to update the end COD table. This update activity which looks into the MDM model, reads the COD entity definition and updates the COD table. The users have to just pick the required activity and configure the properties.
  
  Next, the object instance transits from this state (Update COD) to the Update Spokes state. There, an activity called Synchronize Spokes updates all the spoke systems with this change. From here again, there is an automatic transition to the next state WAIT which does not have any event associated, implying that the transition is taken automatically as soon as the object reaches the state.
  
  To summarize, when a new instance is forwarded to the state engine, the instance would first come into the initial state, update the COD table, update all the spokes and then move to the WAIT state.
  
  The object would reside forever in this WAIT state until an event dbTrigger is received. If you look into the properties of the transition joining the WAIT state and the Update COD state, the event expected is dbTrigger.
  
  Here, when the object comes into the state engine, we would update the COD table, push the changes to all the spokes, and WAIT. Next at the spoke system if the same record changes, the publisher would send that change to MDM Service again, MDM Service identifies that this instance is already registered with state engine through the lookup fields in the modeler and raises the event 'dbTrigger' to the instance.
  
  The insert, update and delete operations link MDM and the state model's events. MDM raises the event that is linked to this incoming database event (operation) to the instance which is already in state engine.
  
  Once MDM Service fires a MDM State Engine event to the instance which is in WAIT state, the state engine recognizes that it must transition to the state Update COD. In the Update to COD operation is performed to synchronize the spokes and finally goes into to the WAIT state waiting for another MDM state engine Trigger.
  
  To design a state model and the states in a state model in Process Platform, refer Designing State Models and Creating a State, respectively.